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We present our extension of ACL2 with Satisfiability Modulo Theories (SMT) solvers using ACL2’s 
trusted clause processor mechanism. We are particularly interested in the verification of physical sys¬ 
tems including Analog and Mixed-Signal (AMS) designs. ACL2 offers strong induction abilities for 
reasoning about sequences and SMT complements deduction methods like ACL2 with fast nonlinear 
arithmetic solving procedures. While SAT solvers have been integrated into ACL2 in previous work, 
SMT methods raise new issues because of their support for a broader range of domains including 
real numbers and uninterpreted functions. This paper presents Smtlink, our clause processor for 
integrating SMT solvers into ACL2. We describe key design and implementation issues and describe 
our experience with its use. 


1 Introduction 

This paper presents Smtlink, a clause processor for using satisfiability modulo theory (SMT) solvers 
to discharge proof goals in ACL2. Prior work has 11211 l23l incorporated SAT solving into ACL2, and 
Manolios and Srinivasan |[T^l22]l described an extension of ACL2 with the Yices SMT solver. Our work 
explores the use of SMT solvers for their decision procedures for linear and non-linear arithmetic which, 
to the best of our knowledge, has not been addressed in prior work. 

Interactive theorem proving and SMT solving provide complementary strengths for verification. 
SMT solvers can automatically discharge proof obligations that would be tedious to handle with an 
interactive theorem prover alone. Conversely, theorem provers provide methods for proof by induction 
and proof structuring methods. While there has been some work on automatically proving induction 
proofs using SMT solvers (see lITSll ). theorem provers such as ACL2 offer a much more comprehensive 
framework for induction proofs. For many problems, SMT solvers cannot prove the main result in a 
single step; in fact, the main theorem may not even be expressible in the logic of the SMT solver. How¬ 
ever, the SMT solver can discharge key lemmas to simplify the proof process, and the theorem prover 
can ensure that the proofs for the main theorems are, indeed, complete. When used from within an in¬ 
teractive theorem prover, the user can identify key goals and relevant facts to make effective use of the 
SMT solver. Doing so can avoid sending the SMT solver down a path of an intractable number of useless 
branches and lead instead to a proof of the desired goal. 

Our intended application of the combination of ACL2 with an SMT solver is to verify properties 
of Analog and Mixed-Signal (AMS) circuits and other cyber-physical systems. AMS circuits are mixed 
analog and digital systems, typically consisting of multiple analog and digital feedback loops operating at 
much different time scales. It is not practical to simulate AMS circuits for all possible device parameters, 
initial conditions, inputs, and operating conditions. In fact, running just one such simulation may require 
more time than the design schedule. Most AMS circuits are intended to be correct for relatively simple 
reasons - errors occur because the designer’s informal reasoning overlooked some critical case or had 
some simple error. Our approach is to verify that the intuitive argument for correctness is indeed correct 
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by reproducing the argument in an automated, interactive theorem prover, ACL2. The advantage of 
using a theorem prover is soundness and generality: by using a carefully designed and thoroughly tested 
theorem prover, we have high confidence in the theorems that it establishes. The critical limitation of 
using a theorem prover is that formulating the proofs can require large amounts of very highly skilled 
effort. Our solution is to integrate a SMT solver, Z3, into ACL2. This allows many parts of the proof, 
especially those involving large amounts of tedious algebra, to be performed automatically. While our 
focus is on AMS, the issues addressed here are common to those in most computing devices and other 
physical systems. 

Our implementation uses ACL2’s trusted clause processor mechanism for integrating external pro¬ 
cedures. Our goal is to provide a flexible framework for developing proofs in a relatively new applica¬ 
tion domain. Thus, our clause processor is designed to be easily configured and modified by the user. 
However, too much freedom to change the behaviour of the clause processor also raises the spectre of 
unsoundness. We address this with a two-pronged solution. Our clause processor is available with a stan¬ 
dard configuration, where the soundness depends mainly on the soundness of ACL2, the SMT solver, and 
a small amount of interface code. There is also a customizable configuration that has a separate trust- 
tag. This facilitates experimentation, but places the burden for soundness directly upon the user. We 
describe our use of the two approaches, and show how this combination provides a flexible environment 
for experimentation and a safe environment for “production” use. 

The key contributions of this work are: 

• We present our software architecture for integrating an SMT solver into ACL2 as a trusted clause 
processor. 

• We describe the issues that arose in this integration, our solutions, and the rationale behind our 
design choices. 

• Our emphasis is on using the arithmetic capabilities of the Z3 SMT solver. This differs from most 
prior work on integrating SMT solvers into theorem provers that has focused on using decision 
procedures for SAT, integer arithmetic, and discrete data structures. 

• We show how some simple customizations of the general framework can lead to a dramatic reduc¬ 
tion in proof effort. 

The rest of this paper is organized as follows: Section [^introduces our clause processor with three 
simple examples. Section [^describes our software architecture, the issues that arise when integrating an 
SMT solver into ACL2, and our solutions to these issues. Sectionj^describes how the SMT interface can 
be customized. In particular, we show how adding a simple inference engine that provides an incomplete 
theory of expt greatly simplifies our proofs for verifying properties of an AMS circuit. Sections [^ and 
present related work and a summary of the current work respectively. 


2 A Short Tour 


This section presents simple theorems that can be proven using Smtlink. The examples here assume 
that the Smtlink book has been downloaded from: 
https://bitbucket.org/pennyan/smtlink 

and certified using cert.pl (see the instructions in the README file). Program 2.1 shows how to 
include the Smtlink book where /dir/to/smtlink is the directory with the Smtlink book. The 
(tshell-ensure) form allows Smtlink to invoke the SMT solver in a separate process. Smtlink 
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Program 2.1 Including the Smtlink book 


1 (add-include-book-dir ;cp "/dir/to/smtlink") 

2 (include-book "top" :dir :cp) 

3 (tshell-ensure) 


Program 2.2 A theorem about a system of polynomial inequalities 


1 (defthm poly-ineq-example-a 

2 (implies (and (rationalp x) (rationalp y) 

3 (<= (+ (* 4/5 X x) (* y y)) 1) 

4 (<= (- (* X x) (* y y)) D) 

5 (<= y (- (* 3 (- X 17/8) (- X 17/8)) 3))) 

6 :hints (("Goal" 

7 :clause-processor 

8 (Smtlink clause nil)))) 


10 (defthm poly-ineq-example-b 

11 (implies (and (rationalp x) (rationalp y) 

12 (<= (+ (* 2/3 X x) (* y y)) 1) 

13 (<= (- (* X x) (* y y)) D) 

14 (<= y (+ 2 

15 (- (4= 4/9 x)) 

16 (- (* X X X x)) 

17 (* 1/4 X X x X X x)) )) 

18 ihints (("Goal" 


19 :clause-processor 

20 (Smtlink clause nil)))) 


supports two configurations. The examples in this section use Smtlink, which uses default settings. The 
other, Smtlink-custom-conf ig, can be configured by fhe user and is described in Section]^ 

Program |2.2| shows two examples involving systems of polynomial inequalities: nil is a list of ad¬ 
ditional hints for the clause processor as no further hints are needed for these examples. Why would we 
want to prove such theorems? Simple, they illustrate the challenges of using ACL2 to reason about sys¬ 
tems of polynomial inequalities as often appear in models of physical systems including AMS verifica¬ 
tion. Without the clause-processor, the proofs fail in ACL2 with the : nonlinearp hint enabled and with 
or without any of the arithmetic books (i.e. arithmetic/top-with-meta, arithmetic-2/meta/top, 
arithmetic-3/top, and or arithmetic5/top). Of course, apatient and savvy user could guide ACL2 
through a sequence of lemmas and eventually discharge the claims. Using the SMT solver, the theorems 
are proven automatically. 

Some theorems, while tedious to prove in ACL2, simply cannot be proven by SMT techniques alone. 
Consider Program |2. 3 1 Again, when just using ACL2, the proof fails with or without a :nonlinearp 
hint or any of the arithmetic books. As formulated, poly-of-expt-example would appear to be 
unsuitable for proof with our SMT techniques because we are using Z3 as our SMT solver, and Z3 
does not support reasoning about non-polynomial functions such as expt. Our solution is to allow 
the user to give hints to the clause processor. These hints allow the user to direct the clause pro- 
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Program 2.3 A claim with non-polynomial arithmetic 


(defthm poly-of-expt-example 

(implies (and (rationalp x) (rationalp y) (rationalp z) (integerp m) 
(integerp n) (< 0 z) (< z 1) (< 0 m) (< m n)) 

(<= (* 2 (expt z n) x y) (* (expt z m) (+ (* x x) (* y y))))) 
:hints(("Goal" 

;clause-processor 

(Smtlink clause ’((:let ((expt_z_m (expt z m) rationalp) 

(expt_z_n (expt z n) rationalp))) 

(;hypothesize ((< expt_z_n expt_z_m) 

(< 0 expt_z_m) 

(< 0 expt_z_n))) 

) )))) 


cessor to replace all occurrences of a given expression with a new, free variable, and to express con¬ 
straints that are satisfied by these variables. A complete description of these hints is presented in Sec- 
tion[^ To prove poly-of-expt-example, we use the clause-processor hint. We also include the book 
arithmetic-5/top. The two : let hints direct Smtlink to replace all occurrences of (expt z m) with 
the variable expt_z_m; furthermore, we are asserting that the value (expt z m) satisfies rationalp. 
Likewise for expt_zji replacing all occurrences of (expt z n). The fhree : hypothesize hinfs sfafe 
addifional consfrainfs on fhe values of expt_z_m and expt_z_m for use by fhe SMT solver. Wifh fhese 
subsfilufions and consfrainfs, Z3 readily discharges fhe main claim. 

For ibis approach fo be sound, fhese subsfifions, fype-asserfions, and consfrainfs musf all be implied 
by fhe hypofheses of fhe original fheorem. If fhe SMT solver discharges fhe main claim, fhen Smtlink 
refums each of fhese added assumptions and new clauses fo be proven by ACL2. In ofher words, Smtlink 
has replaced a clause fhaf would be difficulf fo prove using ACL2 alone, wifh a moderafe number of 
simpler clauses fhaf are simpler for ACL2 fo esfablish, plus one clause (fhe augmenfed, original claim) 
thaf is proven by fhe SMT solver. In fhis case, runes from arithmetic-5/top enable fhe relumed 
clauses fo be discharged wilhouf furfher assisfance. This also illusfrafes fhe synergies fhaf are available 
by combining SMT fechniques wifh fheorem proving. 


3 Software architecture of Smtlink 


Figure [T] shows fhe slruclure of Smtlink. The clause processor franslafes ACL2 clauses info a Pyfhon 
represenlalion inspired by Z3’s Pyfhon API. The Iranslalion process is divided info Iwo phases. The firsl 
phase franslafes from ACL2 fo ACL2. This Iranslalion allows fhe clause-processor fo accepf a fairly 
expressive subsel of fhe ACL2 language while fhe expanded clauses oulpul by fhis phase use only a 
small sef of primitive Lisp funcfions (See Section 3.2.2| ). The second phase franslafes fhe simplified (buf 
expanded) ACL2 clauses fo our Pyfhon API - fhis process is fhe main “Irusfed” aspecf of our Irusled 
clause processor. The SMT solver verifies a clause by showing fhaf ils negafion is unsalisfiable. If fhis 
is fhe case, fhen Smtlink refums a lisl of clauses for subgoals fhaf arose in fhe iranslalion process. 
Essentially, Smtlink asks ACL2 fo verify fhaf fhe expanded clause implies fhe original, and fo verify 
any lype assertions or addifional hypofheses fhaf were provided by fhe user. If fhe SMT solver fails fo 
show fhaf fhe clause is unsalisfiable, if lypically provides a counter-example fhaf Smtlink fhen prinls 
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Figure 1: Top-level arehitecture of Smtlink 


Program 3.1 A putative theorem without type constraints 


(defthm not-really-a-theorem 

(iff (equal x y) (zerop (- x y))) ) 


to the ACL2 comment window, although is some cases it may simply report that the satisfiability of the 
clause is “unknown”. In these cases, Smtlink prints the counter-example or “unknown” status to the 
ACL2 comment window and aborts the proof attempt. 


3.1 The first translation phase 


The first phase of translation transforms clauses written in a fairly expressive subset of ACL2 into a very 
small subset. Most of the complexity of the translation process is in this first phase. As described in 
Section 3.3 Smtlink constructs a new clause that is proven by ACL2 to validate this translation. The 
key issues in the first phase are: 


• ACL2 is untyped whereas SMT solvers support many-sorted logics. 

• ACL2 clauses often include user-defined funcfions. 


• The user may add fype asserfions and/or exfra hypofheses fo enable fhe SMT solver fo discharge a 
claim. These musf be verified by ACL2. 

• The user may need fo provide hinfs fo enable ACL2 fo discharge subgoals fhaf are relumed by fhe 
clause processor. 


3.1.1 Types 

Consider fhe pulafive fheorem shown in Program [3.1| ACL2 is unlyped and requires all functions fo be 
lolal. Accordingly, (- x y) is defined for all values for x and y, including non-numeric values. As 
defined in ACL2, arilhmefic operators such as - Ireal non-numeric values as if fhey were 0. Thus, x = 
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Program 3.2 A simple theorem with type constraints 


(defthm rational-minus-and-equal 

(implies (and (rationalp x) (rationalp y)) 

(iff (equal x y) (zerop (- x y))) )) 


Mog and y = (list "hello" 2 ’world) is a counter-example to not-really-a-theorem. On 
the other hand, Z3 uses a typed logic, and each variable must have an associated sort. If we treat x and y 
as real-valued variables, the z3py equivalent to not-really-a-theorem is 

»> X, y = Reals([’x’, ’y’]) 

»> prove ((x == y) == ((x - y) == 0)) 
proved 

In other words, not-really-a-theorem as expressed in the untyped logic of ACL2 is not a theorem, 
but the “best” approximation we can make in the many-sorted logic of Z3 is a theorem. To solve these 
problems, Smtlink requires that each free variable in a theorem is constrained by an ACL2 type rec¬ 
ognizer such as integerp and rationalp. These are then translated to corresponding SMT sorts with 
the design requirement that the set of values in the SMT sort must be a superset (or equal to) the set of 
values admitted by the type recognizer. 

Although ACL2 is untyped, it is common for users to include assertions such as (rationalp x) that 
constrain the types of free-variables appearing in a theorem. Program |3.2| shows the previous, putative 
theorem with type recognizers added to the hypotheses. ACL2 proves rational-minus-and-equal 
without any assistance from the user. Note that rational-minus-and-equal holds for all values of x 
and y including values that are not rational, and values that are not even numeric, such as x = ’ dog and 
y = (list "hello" 2 ’world). For such cases, the antecedent of the theorem is not satisfied, and 
the theorem holds vacuously. 

Let G be the clause to be proven by Smtlink; G is the “goal”. In the first translation phase, Smtlink 
traverses G looking for terms of the form (typep var) where typep is one of booleanp, integerp, or 
rationalp; var is a symbol (but not nil); and the clause holds vacuously if (not (typep var) ). 
In other words, such terms are type hypotheses. Smtlink identifies type hypotheses syntactically by 
walking the tree for the expression, recognizing the constructions for if, implies, not, and the type- 
recognizers (note: the ACL2 macros “and” and “or” expand to terms written with if). 

Let T = (list T\ T 2 . ■ - Tm) be the list of all type-hypotheses; T denote the conjunction of the 
elements of T ; and and Gj be G rewritten by replacing each of the Tj ’s with the boolean constant t. We 
could now construct the terms T Gj, TVG, and {{T V G) A (T Gt)) G. We could then invoke 
the SMT solver to determine if Gj holds for all valuations of the free variables that satisfy T. If the 
SMT solver can show this, then T ^ Gt is established. Then, we could return the terms T V G, and 
((r V G) A (r Gr)) G to ACL2 to be proven. If these proofs are successful, then we can conclude 
that G is a theorem as well. Smtlink uses this approach; however, rather than checking each step of the 
first translation phase, it checks the final result. Section describes this process. 


3.1.2 Functions 


The second phase of translation supports a small set of ACL2 built-in functions (see Section 3.2 1 . 
Smtlink handles other functions by expanding their calls. In particular (fun actual-parameters) be- 
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Program 3.3 lexpand hint 


1 :hints(("Goal" 

2 :clause-processor 

3 (Smtlink ’( ... 

4 (: expcind ((:functions ((funl typelp) (fun2 type2p) 

5 (funk typekp))) 

6 (:expauision-level 1))) 

7 ...)))) 


comes 

((lambda (fresli-variables-for-formals) body-of-fun) actual-parameters) (1) 

Because body-of-fun may have function instances that need to be expanded, Smtlink recursively applies 
this function-expansion operation to body-of-fun and each term in actual-parameters. 

If the function/un has a recursive definition, then the expansion procedure described will not termi¬ 
nate. To avoid this problem, we require the user to specify a maximum expansion depth and the return 
type for each function. Smtlink replaces each call beyond the expansion limit with an unconstrained, 
fresh SMT variable of the specified refurn fype. The fype-hypofhesis for each such variable is added fo 
fhe fype-hypofhesis lisf, T, and fhe function call insfance fhaf fhis variable replaces is added fo a lisf of 
function calls insfances, F. As described in SectionSmtlink produces a clause for ACL2 fo check 
fo verify fhaf each funcfion call in F refums a value of fhe user-claimed type. Replacing the function’s 
return value with an unconstrained variable is a simple form of generalization. 

The user controls function expansion by Smtlink with a : expand hint as shown in Program |3. 3 1 
Each function is specified wifh ifs refum type, and the :expansion-level parameter specifies fhe maximum 
depfh fo which any funcfion will be expanded. We wrife Gf to denofe fhe clause produced by expanding 
fhe funcfion calls in Gt- 

Smtlink also supporfs franslafing function calls in ACL2 into uninterpreted function instances. For 
example, 

(:uninterpreted-functions ((expt rationalp integerp rationalp))) 
says that the function expt should be treated as an unintepreted function whose first argument satisfies 
rationalp, whose second argumenf satisfies integerp, and whose refurn value satisfies rationalp. 
Smtlink records each uninferprefed funcfion declaration in a lisf, U, and each call in F. 

The mechanisms for funcfion expansion and uninferprefed funcfions are similar. In parficular, fhe 
replacement of a recursive function call with a fresh variable is a weaker version of replacing it with 
an uninterpreted function. On the other hand, we discovered that Z3 does not combine its theories of 
non-linear arithmetic and uninterpreted functions: if a formula includes an uninterpreted function, the 
non-linear arithmetic solver is silently disabled. Thus, in many cases, using fresh variables is preferred to 
using uninterpreted functions. We are examining these trade-offs in examples of real proofs and expect to 
formulate a more unified freafmenf of funcfion expansion and uninferprefed funcfions in a fufure version 
of Smtlink. 

3.1.3 Adding Hypotheses 

Offen, fhe proof of a fheorem may depend on resulfs fhaf have already been esfablished in ACL2’s logical 
world. However, Smtlink only franslafes fhe currenf goal for fhe SMT solver. In pracfice, fhis is crifical: 
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while it is tempting to give the SMT solver every constraint that might be relevant, this would often 
cause the SMT solver to require more time or memory than is available for the proof. A key feature 
of the integration of SMT solvers into a theorem prover is that the user can identify the relevant facts, 
and these can be included with : hypothesize hints as illustrated in Program |2.3| Of course, the user 
can include any term they like in these hints. If the SMT solver discharges the clause, then each of the 
: hypothesize hints is returned as a subgoal. If it corresponds to a previously proven theorem, then 
ACL2 will (usually) discharge it without any further assistance. We write H to denote the set of all 
hypotheses introduced by : hypothesize hints, H to denote the conjunction of the elements of H, and 
Gjj=H=>Gf = ^H V Gp to denote the goal clause augmented with these hypotheses. 

3.1.4 Substitutions 

Proof goals may include terms that do not have a representation in the theories of the chosen SMT solver. 
For example, the theorem in Program |2.3| used the expt function that raises its first argument to an 
arbitrary integer power and is not representable in Z3 which only supports fixed-degree polynomials and 
rational functions. Rather than abandoning the advantages offered by the SMT solver, Smtlink allows 
the user to specify a replacement of offending sub-expressions by fresh variables of the appropriate 
types. All occurrences of the given sub-expression are replaced by the specified variable. This is another 
example of generalization by replacing the return value of a function with a fresh variable. It is quite 
common, in our experience, to combine these substitutions with : hypothesize hints that constrain the 
values of these variables. Furthermore, the type-hypothesis for each new variable is included in the 
type-hypotheses list, T, and the substitutions are recorded in a list S. 

These substitutions are the final step of the first phase of translation. We write G' to denote the result 
of this first phase, and refer to it as the “expanded clause”. 

3.2 The second translation phase 

Given an original goal, G, along with user provided hints, the first translation phase produces an “ex¬ 
panded goal”, G'; a list of type-assertions, T ; a list of functions to be treated as uninterpreted, U ; a list 
of function call instances, F \ a list of additional hypotheses, H\ and a list of substitutions, S. The second 
translation phase uses these to produce the variable declarations for the SMT solver and the claim that 
the SMT solver is to discharge. If the SMT solver shows that (not (implies H G') ) is unsatisfiable 
for valuations of the free variables that satisfy the type-hypotheses, T, and the uninterpreted function 
definitions, U, then Smtlink concludes that (implies H G') is a theorem. Unlike the first phase, the 
results of the transformations performed in this second phase are not returned to ACL2 to be verified. 
Our design goal was to keep this part of the connection as simple as possible to avoid errors and enable 
code inspection by cautious users. 

3.2.1 Types 

For each free-variable, Xi, occurring in G (and thus in G') there should be a corresponding type-assertion, 
Ti that is a conjunct of T. For each type assertion, [typepi varj), Smtlink generates a corresponding 
variable declaration for the SMT solver. For example, 

(rationalp x) 
translates to 

= _SMT_.isReal("x") 


X 
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Program 3.4 The irrationality of \/2 


(defthm sqrt-of-2-is-irrational 

(implies (rationalp x) (not (equal (* x x) 2 )))) 


In our implementation, the Python interface to the SMT solver is in the form of an object, _S]yiT_. For 
example, _SMT_. isRealC'x") creates areal-valued, symbolic variable for the SMT solver that underlies 
_SMT_. If a type-assertion is omitted, then an undeclared variable will appear in the formula to be checked 
by the SMT solver, and the SMT solver will report an error and fail. 

For soundness, if Smtlink maps the ACL2 type recognizer typepj to the SMT sort sorti, then every 
value that satisfies typepi must be an element of sorti. Note that sorti may include other values as well, 
this simply strengthens the claim G' and may result in a failure to prove a valid goal, but this will not 
cause Smtlink to prove an invalid goal. Smtlink maps the ACL2 type recognizers booleanp to SMT 
booleans; the type correspondence is strict. The type recognizers integerp and rationalp are both 
mapped to SMT reals. We did this because most SMT solvers (e.g. Z3) provide decision procedures 
for real numbers, whereas ACL2 provides rationals. As noted above, this strengthens the claim. For 
example, the theorem shown in Program |3.4| can be proven in ACL2 ITOl . we cannot discharge it using 
Smtlink. It will report the counter-example for x equal to the square-root of two, described as an 
algebraic number. Smtlink can also be used with ACL2r, in which case the mismatch between rationals 
and reals can be avoided entirely. 

Our choice to broaden integerp to SMT rationals (instead of SMT integers) was pragmatic. Our 
initial implementation uses the Z3 SMT solver, and we make extensive use of its non-linear arithmetic 
solver. Z3 disables the non-linear solver when a formula includes integer-valued variables. By mapping 
ACL2 integers to SMT reals, Smtlink strengthens the theorem. We expect to add mechanisms to allow 
the user to control whether ACL2 integers map to SMT integers or reals in a future version of Smtlink. 

3.2.2 Functions 

The nine functions supported are binary-+, unary—, binary-*, unary-/, equal, <, if, not, and 
lambda along with the constants t, nil, and arbitrary integer constants. As in ACL2, integers in Python 
can be arbitrarily large; thus, Smtlink translates them directly. Smtlink translates ACL2 lambda ex¬ 
pressions into Python lambda expressions. The other eight functions are translated directly to their 
counterpart methods of the _SMT_ object. For example, the ACL2 function binary-* is mapped to 
_SMT_.plus. Smtlink generates declarations for all uninterpreted functions, again using the _SMT_ in¬ 
terface. 

If G' includes any functions that are not in the list of eight above or in U, then Smtlink will not 
prove G but instead will fail with an error message. In particular, unexpanded occurrences of user- 
defined funcfions will creafe an error. Furfhermore, any fype-recognizer such as rationalp in G' will 
creafe an error - Smtlink requires fhaf all fype-recognizer ferms occur in confexfs fhaf if can recognize 
as fype-hypofheses; ofhers generafe errors. Likewise, G cannof include quanfificafion operators such as 
exists or forall. This ensures fhaf all variables appearing in G' are free which is essential for our 
approach of using SMT sorfs fhaf are super-sefs of fheir ACL2 equivalenfs. For example, one cannof 
sfafe a fheorem fhaf 2 has a rafional square roof and “prove” if using Smtlink fo find a real-valued x 
such fhaf x*x = 2. 

In fhe SMT world, each operafion (such as +) is defined for specific sorfs for ifs argumenfs and 
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defined to to produce a (symbolic) value of a specific sort for its result. Some of these operations (such 
as +) are overloaded to operate on multiple types. If an operator is applied to arguments for which it is not 
defined, then the SMT solver fails, and Smtlink fails to prove the goal. For example, if the original goal, 
G, (and thus G') includes a term of the form (+ x b) where x is real and b is boolean, then the SMT 
solver will fail even though the operation is defined in ACL2. This interpretation of ACL2 operators is 
conservative: Smtlink will not discharge an invalid theorem due to the type restrictions of operators in 
the SMT world. 

Smtlink translates (/ m) in ACL2 to _SMT_.reciprocal(m), where the SMT function divides 
the constant 1 by m. If m / 0, the ACL2 and SMT operations are identical. If m = 0, then the SMT 
version produces an unconstrained integer (if m is an integer) or real (if m is real). The ACL2 operator 
is defined to return 0. Because the SMT version allows the ACL2 semantics, the SMT version is more 
general. Thus, Smtlink proves a more general claim, and a proof of G' implies a proof of G. This relies 
on our restriction that G cannot include quantification operators. 


3.2.3 Hypotheses and Substitutions 

These are handled entirely in the transformation of the original goal, G, to the expanded goal, G', in the 
first translation phase and do not impact the second phase. 


3.3 Ensuring soundness 

Our design goal with Smtlink has been to trust ACL2, the chosen SMT solver (Z3, in our current 
implementation), and as little other code as practical. At the same time, our intended use for Smtlink 
is for the verification of AMS circuits and other cyber-physical systems. Because we are developing 
verification techniques as we go, we want Smtlink to provide a flexible framework for prototyping new 
ideas. Our solution is to put most of the functionality and complexity of Smtlink into the first translation 
phase. If the SMT solver discharges the translated clause, then Smtlink generates a set of return clauses 
to check the correctness of this translation. The second phase is trusted; this code is both small and 
simple. 

Our basic approach is simple: let A denote the additional assumptions that were added to the goal by 
type assertions for variables and function return values, hypotheses, and substitutions. Let Gsmt denote 
the clause that is tested by the SMT solver. If the SMT solver proves Gsmt, then Smtlink returns the 
clauses 

<2i = (G'AA)^G 

Q2 = AVG ^ ’ 

for proof by ACL2. We are trusting the translation of G' to Gsmt and the SMT solver itself. Modulo that 
trust, the truth of Gsmt implies the truth of G'; in which case Qi is equivalent to A G. Accordingly, 
when ACL2 proves Qi and Q 2 , G is established as a theorem. 

We make two observations before describing how each step of the translation process contributes to 
A. First, the correctness of this argument does not depend on the choice of A. Of course, deriving the 
intended A is important to ensure that Qi and Q 2 can actually be proven. Second, A is the conjunction of 
the various assumptions that were added by Smtlink. Smtlink expresses Q 2 as a separate subgoal for 
each conjunct of A. 
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3.3.1 Types 

Each type-hypothesis identified by Smtlink is included in A. Let Ti = [typep^ vari) be such a type- 
hypothesis. When proving Q 2 , ACL2 verifies TiW G which means fhaf for all values of var, fhaf do 
nol safisfy typep^, G frivially holds. By fhe frusf fhaf Smtlink declares var, fo be of an SMT sorf fhaf 
includes all values fhaf safisfy typepf, fhe franslafion is valid. 

3.3.2 Functions 

When a function call is expanded in fhe firsl franslafion phase, fhe equivalence is checked by ACL2 when 
if verifies Qi. We are frusfing fhe franslafion of ACL2 lambda-expressions fo fheir Pyfhon equivalenfs in 
phase 2. When a funcfion call is replaced by a variable, ACL2 musf check fhaf fhe user-claimed fype for 
fhe refum value of fhe funcfion is valid. This is done by generafing a clause for each funcfion call in F. 
Eel / be such a function call (i.e. an ACL2 ferm), and lef typef be fhe user-claimed type for fhe refurn 
value of /. Smtlink includes a conjuncf of fhe form 

{or {typef f) G) (3) 

in Q 2 . A fechnical defail is fhaf / may include variables fhaf are bound by lambda expression arising 
from ofher funcfion expansions; such variables are free in fhe clause depicfed in Equation]^ as generated 
by Smtlink. This means fhaf fhese variables are less consfrained in fhe check performed by ACL2 fhan 
fhey are in G' or Gsmt- Because ACL2 has proven fhe more general case, we can safety conclude fhe 
more resfricfed version as well. 


3.3.3 Added Hypotheses 

Each hypothesis. Hi, added by the user, is included in A. The clause {Hi V G) is verified by ACL2; 
therefore, it is safe to add Hi as a hypothesis for G' (and thus for Gsmt)- 

3.3.4 Substitutions 

Smtlink records the user-defined substitutions in the list S. When generating Q\ and Q 2 , Smtlink uses 
lambda expressions to bind the variables declared in substitution hints to their corresponding expressions 
- this is similar to the way that function expansions are handled. Eurthermore, the user-claimed types of 
these expressions are included in T, and Smtlink generates clauses for ACL2 to check these claims in 
the same manner as checking the types of values returned by function calls. 


3.3.5 The Python Interface 


Smtlink relies on software packages that are outside the ACL2 world, namely the Python interpreter 
and an SMT solver (Z3 for the purposes of this paper). This creates the potential unsoundness that these 
external components can be modified without detection. Our implementation of Smtlink takes several 
measures to prevent the most likely causes of unsoundness. Eirst, Smtlink has a default configuration 
that is encoded in config.lisp. There is a script for creating config.lisp; once run, the config¬ 
uration includes full path names to the Python interpreter and sets the path variable for searching for 
Python classes. Likewise, the Python code to define the class for the interface object, _SMT_ described 


in Section [T2] is provided as the string returned by the function ACL22SMT. The file ACL22SMT.lisp 
is generated from a Python source file that is specific for the intended SMT solver. The consequence of 
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this approach is that the paths to the Python interpreter and the SMT solver (and therefore the choice 
of the SMT solver), along with the Python class definition for the interface between Smtlink and the 
SMT solver are all baked into the certified ACL2 code for Smtlink. We believe that this should make 
Smtlink quite robust to unintentional changes of the computing environment. Of course, a nefarious 
user could replace the executable image for the Python interpreter, or the dynamic library for the SMT 
solver, but these are in “system” directories (under /usr/bin in our installation) rather than user direc¬ 
tories; so such changes are unlikely to be accidental. Such changes are likely to occur as a consequence 
of regular software updates. We are considering adding checksum information to our config.lisp to 
ensure that such changes are detected and reported. We would like to devise an SMT-solver independent 
way of recording such checksums. 

3.3.6 Remarks 

In the current implementation of Smtlink, the construction of the goals Qi and Q 2 is done within the 
trusted code of the clause processor. Although the arguments for the correctness of these constructions 
are straightforward, the fact that this is unverified code does present a risk of errors. As we have learned 
more about ACL2, we now see that an alternative would be to restructure Smtlink to provide a function 
that returns G' and the lists T, F, U, H, and S described above. From these, a local theorem, that G' 
holds would be proven using a trusted clause processor corresponding to phase 2 of the current Smtlink. 
Additional local theorems would be proven by ACL2 to prove Qi and each clause of Q 2 from Equation]^ 
Then, the main theorem, G would be proven by ACL2 using these local theorems. This should be a 
relatively straightforward restructuring Smtlink that would isolate the small amount of trusted code. 
We plan to do this in the near future. 

Even greater confidence could be achieved by adopting the “skeptical” approach advocated by Har¬ 
rison ca, for example by using proof reconstruction |0 [iTl |2l [181 or proof certificates ['5!|. We see 
such efforts as complementary to the approach that we have taken with Smtlink. We are using Smtlink 
to develop proof methods for domains where formal methods have had little prior use. As described in 
Section]^ the relatively lightweight interfaces in Smtlink facilitate such experimentation. We gain this 
flexibility at the risk that an error in critical parts of our code (or in the SMT solver itself) could lead to a 
“proof” of a non-theorem. We believe that this risk is small compared with other risks that are inherent 
in the verification of physical artifacts: most notably, “Does the model of the physical system actually 
capture all possible behaviours?” Being able to prototype and develop proofs quickly lets us explore 
the consequences of the models more thoroughly than would be possible with a less flexible approach. 
Thus, we regard the slight risk of an error as being justified by the opportunity to verify designs that are 
otherwise outside the reach of formal tools. We see this as complementary to work on proof reconstruc¬ 
tion and proof certificates. If we demonstrate the kinds of proofs that are useful in practice, that should 
illuminate where proof reconstruction and certificates would offer the greatest increase in confidence in 
critical designs. 


4 Customizing Smtlink 


The design choices described in Section 3.3.5 protect the user from unintentional changes to the external 
components of Smtlink. What if such changes are desired? To facilitate such experimentation, we 
provide a second version of Smtlink, Smtlink-custom-conf ig, where the user can easily change 
the configuration of external components. Using Smtlink-custom-conf ig requires a different trust- 
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Table 1: Rules for expt 


1. (expt X 0) —7- 1 

2. (expt 0 n) —7- 0, if n > 0 

3. (expt X (+ nl n2)) —)• (* (expt x nl) (expt x n2)) 

4. (expt X (* c n)) —)• (* (expt x n) (expt x n) ... (expt x n)) 

5. (< (expt X m) (expt x n)), if 1 < x and m < n 

6 . ... 

Notes: All rules have a precondition of that either the base is non-zero or the exponent is positive; 
furthermore, new instances of expt are only generated if they can be shown to satisfy the same condition. 
For rule 4, the right-hand side of —)> is the multiplication of c copies of (expt x n). Rule 4 is only 
applied if c is small and positive. 


tag than that for the standard configuration, Smtlink. Thus, it is easy to track theorems whose proofs 
descend from a custom configuration of the clause processor. The remainder of this section describes 
one such custom configuration to illustrate how these features facilitate experimentation. 

Our largest use of Smtlink to date has been the proof of global convergence for a digital phase- 
locked loop (The code can be found at ifT^ and see ll20l for more details.). The original proof was a 13 
page long latex document, with lots of tedius algebra. Using the standard configuration of Smtlink, we 
completed the same proof using ACL2. The proof is about 1700 lines of ACL2 code. While Smtlink 
made the proof possible, it didn’t make it as easy as we had hoped. A key complication is that the phase- 
locked loop (PLL) model uses recurrence functions whose solutions make extensive use of ACL2’s 
expt function. As described earlier, Smtlink can handle these, but each occurrence requires : let and 
: hypothesize hints. Furthermore, function expansion renames variables; so, the proofs involved many 
lemmas whose sole purpose was to explicitly expand functions and rewrite terms so as to make the calls 
to expt visible in the theorem statement and thus amenable to these hints. 

Our solution was to define a new Pyfhon class for fhe _SMT_ inlerface objecf. This class is called 
RewriteExpt, and if extends fhe defaull ACL2_to_Z3 thaf was complied info ACL22SMT. lisp as de¬ 
scribed above. To use fhis exfension, expt is declared fo be an uninferprefed function. RewriteExpt 
overrides fhe _SMT_.prove mefhod fo add a pre-processing step finds insfances of expt in fhe claim. 
For each insfance, fhe code checks fo see if fhe hypofheses of fhe fheorem imply fhe guard for expt: 
fhe base musf be non-zero, or fhe exponenf musf be non-negafive. If fhe guard can’f be proven, an error 
is reporfed and fhe proof fails. Ofherwise, RewriteExpt applies a small number of simple proof rules 
abouf expt. If fhe anfecedenf of one of fhese rules is safisfied, fhen fhe consequenf is added as a new 
hypofhesis. Table [T] shows some examples of fhese rules. 

Preliminary experimenfs wifh fhis cusfomized clause processor have been very promising. For exam¬ 
ple, one fheorem in fhe PLL proof fhaf required 19 supporting lemmas for a tofal of 334 lines of ACL2 
code was replaced by a single fheorem sfated in 13 lines of ACL2 code. The proofs wifh fhe cusfomized 
clause processor are much shorter, much simpler, and much easier fo undersfand. 

We are in fhe process of wrifing a new proof for fhe PLL based on fhe cusfomized clause processor. 
We see many directions fhaf we could pursue fo extend fhis approach after revising fhe PLL proof. Firsf, 
the customized clause processor uses a set of proof-rules that are hard-coded into RewriteExpt .py. 
These correspond to runes for existing ACL2 theorems about expt. We expect that we could forward 
such runes from ACL2 to the SMT interface and write a simple, generic inference engine in Python. 
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The advantage of performing the inference with the SMT solver is that it can discharge pre-conditions 
for runes that ACL2 does not resolve with its waterfall. On the other hand, the ACL2 framework is 
much more general than what can be described in the theories of an SMT solver; so we see the two 
as complementary. We also note that once our inference engine has discovered a useful hypothesis, 
it also has the justification. Thus, we could return these to ACL2 and use them to generate the : let 
and : hypothesize needed to discharge the goal with the standard configuration of Smtlink. If this 
approach were implemented, then our customized processor would be an elaborate computed hint, but 
the goal would be discharged with Smtlink, and no additional trust would be required. 


5 Related work 

There has been extensive work in the past decade on integrating SAT and SMT solvers into theorem 
provers. Srinivasan |[22l integrated the Yices p8T] SMT solver into ACL2 for verifying bit-level pipelined 
machines. They also use the mechanism of a trusted clause processor with a translation process quite 
similar to ours. They appear to have mostly used the bit-vector arithmetic and SAT solving capabilities 
of Yices. While they also produce an expanded formula that is then translated to SMT-LIB |4], they don’t 
describe using ACL2 to check this translation as we have done. Prior to that, in IIT 6 II . they integrated a 
decision procedure called UCLID lfT4l into ACL2 to solve a similar problem. 

Works on integrating SMT solvers or techniques into other theorem provers include ifTTl |9l ID |2l |T8l 
laiTi. Many of these papers have followed Harrison and Thery’s “skeptical” approach IfTTl and focused 
on methods for verifying SMT results within the theorem prover using proof reconstruction, certificates, 
and similar methods. Several of the papers showed how their methods could be used for the verification 
of concurrent algorithms such as clock synchronization f9j, and the Bakery and Memoir algorithms lITSl . 
While lO used the CVC-Lite f3l] SMT solver to verify properties of simple quadratic inequalites, the use 
of SMT in theorem provers has generally made light use of the arithmetic capability of such solvers. In 
fact 10 (Isabelle/Sledgehammer with Z3) reported better results for SMT for several sets of benchmarks 
when the arithmetic theory solvers were disabled! 

The work that resembles our approach is fJl ; they present a translation of Event-B sequents from 
Rodin [T] to the SMT-LIB format 14). Like our work, ||71 verifies a claim by using a SMT solver fo show 
fhaf ifs negafion is unsafisfiable. They address issues of fypes and functions. They perform exfensive 
rewrifing using Evenf-B sequenfs, and fhen have simple franslafions of fhe rewriffen form info SMT-LIB. 
While noting fhaf proof reconsfrucfion is possible in principle, fhey do nof appear fo implemenf such 
measures. The main focus of fTj is supporfing fhe sef-fheorefic consfrucfs of Evenf-B. In confrasf, our 
work shows how fhe procedures for non-linear arifhmefic of a modem SMT solver can be used when 
reasoning abouf analog and mixed-signal circuifs. 

Our work demonsfrafes fhe value of fheorem proving combined wifh SMT solvers for verifying 
properfies fhaf are characferized by funcfions on real numbers and vecfor fields. Accordingly, fhe linear 
and non-linear arifhmefic fheory solvers have a cenfral role. As our concern is bringing fhese fechniques 
fo new problem domains, we deliberafely fake a pragmatic approach fo infegrafion and frusf bofh fhe 
theorem prover and the SMT solver. 

Prior work on using theorem proving methods to reason about dynamical systems includes ifT^ 
which uses the Isabelle theorem prover to verify bounds on solutions to simple ODEs from a single initial 
condition. Harutunian |[T2]| presented a very general framework for reasoning about hybrid systems using 
ACL2 and demonstrated the approach with some very simple examples. Here we demonstrate that by 
discharging arithmetic proof obligations using a SMT solver, it is practical to reason about much realistic 
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6 Conclusion and future work 

This paper presented Smtlink, a clause-processor that we have used to integrate the Z3 SMT solver into 
ACL2. Reasoning about systems of polynomial and rational function equalities and inequalities can be 
greatly simplified by using Z3’s non-linear arithmetic capabilities. ACL2 complements Z3 by providing 
a versatile induction capability along with a mature environment for proof development and structuring. 
Smtlink offers two configurations: the default, standard configuration where the interface code and the 
pathways to the external tools (Python and Z3) are fixed when book is certified; and a customizable 
interface that allows the user to experiment with extending these capabilities. 

Section [^described our software architecture, issues that arose when integrating an SMT solver into 
ACL2, and our solutions to these issues. A key aspect of the design is a two-phase translation process 
for converting ACL2 clauses into formulas that can be discharged by the SMT solver. The first phase 
translates a fairly expressive subset of ACL2 into a simple subset consisting of nine built-in functions. 
This first phase includes methods for handling types, function expansion, uninterpreted functions, and 
sub-expression replacement; all of these can be understood as various versions of generalizing the origi¬ 
nal clause to produce a stronger clause that is suitable for discharging with an SMT solver. Most of the 
complexity of the translation process is in the first phase. Because ACL2 verifies that the clause produced 
by this first phase implies the original, this first phase greatly improves the usability of the clause proces¬ 
sor while raising minimal concerns about soundness. The second phase transliterates the nine remaining 
functions to equivalents in a Python API - this is the code that is most critical for sondness. 

Section [^showed how the customizable interface can be used to automate tedious aspects of a mod¬ 
erately large (1700 line) proof that we performed with the original version of the clause processor. By 
adding a few simple rules for transforming expressions involving the ACL2 expt functions into the 
SMT interface, we showed that we could dramatically reduce the length and complexity of some of the 
proofs. We believe that this demonstrates the value of Smtlink as an experimental platform. Once 
a proposed functionality is shown to have sufficient value, then a more rigorous version could be im¬ 
plemented. The fast prototyping that is enabled by Smtlink can help guide this process by avoiding 
investing large amounts of effort on some approach that ultimately provides small improvements to the 
proof development process. 

Prior work on integrating SMT solvers into theorem provers has focused on using the non-numerical 
decision procedures of an SMT solver. Our work focuses on the value of bringing an SMT solver into a 
theorem prover for reasoning about systems where a digital controller interacts with a continuous, analog, 
physical system. The analysis of such systems often involves long, tedious, and error-prone derivations 
that primarily use linear algebra and polynomials. These are domains where SMT solvers combined with 
induction and proof structuring have great promise. 


6.1 Future work 

Smtlink returns clauses to ACL2 to check the translation of the original goal to a small subset of ACL2. 
As noted in Section 3.3.6 a moderate restructuring of this code could allow most of this work to be done 
within ACL2 and reduce the amount of code that must be trusted in Smtlink. We believe that this could 
be done with minimal impact on the flexibility of Smtlink for experimenting with SMT solvers and their 
applications. 
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We have used ACL2 with Smtlink to prove the most challenging part of a global convergence 
argument for a digital Phase-Locked Loop (PLL) using Smtlink. Global convergence is a response 
property, and we can show that the PLL makes progress through four distinct phases. We used ACL2 
with Smtlink to verify the phase for which a hand-written proof was the most complicated. We would 
like to write proofs in ACL2 for the other three phases and use ACL2 to prove that those results are 
sufficient to prove correct convergence from any initial condition. This will involve constructing Skolem 
functions to compose the individual pieces of the proof and should demonstrate the strength of using 
ACL2 to prove properties that cannot be expressed in the logic of the SMT solver. 

We would like to add a bounded model checking capability to SMT link. For example, in the PLL 
proof, there is a tedious proof at the boundary of two of the phases. Z3 provides an “easy” proof by 
showing that within eight steps of the recurrence, the transition between phases is complete and correct. 
We would Ike to integrate this capability into Smtlink and thus into ACL2. 

The current implementation of Smtlink provides very restricted support for recursive functions. 
This is because most recursive functions are non-numerical and/or use “fixing” funcfions or recognizers 
fo ensure ferminafion when called wifh bogus argumenfs. While fhis has nol been problemafic for our 
PLL proof, we would like fo generalize fhe handling of fypes by Smtlink fo allow a wider range of 
applicafions. 

Many of fhe fype-checking steps performed by Smtlink reconsfrucf facls fhaf are already presenf in 
ACL2s type-alist. We would like fo see if fhis informalion could be used by Smtlink and fhus spare 
fhe user of many of fhe fype declaration fhaf Smtlink now requires. 

Presenfly, Smtlink prinfs counfer-examples from fhe SMT solver fo fhe ACL2 commenf window. 
We would like fo make fhem available fo fhe user wifhin fhe ACL2 environmenf. This could be similar 
fo fhe env$ argumenf used in Satlink. New issues arise in fhe SMT case because SMT formulas donT 
have a single, synfacfical form like CNF for SAT. Furfhermore, if fhe counfer-example included irrational 
numbers, fhen if cannof be represenfed in ACL2 - allhough fhis should be addressed in ACL2(r). 
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